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(54) Packet classification engine 

(57) Packet classification apparatus includes a rule 
memory and a criterion memory. One ^pe of rule mem- 
ory entry contains an operaloranda pointer to a criterion 
memory entry. The operator def&ies a comparison op- 
eration to be performed, such as EQUAL (exact match) 
or LESS TIHAN. The criterion memory entry contains 
one or more values to be used as comparands on one 
side of the comparison, where corresponding values 
from a received padcet appear on the other side of the 
comparison. Control logic responds to packet classifi- 
cation requests to retrieve a rule memory entry from the 



rule memory, retrieve the criterion memory entry identi- 
fied by the criterion memory pointer In the rule memory 
entry, and perfonn the operation specified by the oper- 
ator in the rule memory entry on the values In the crite- 
rion memory entry and con'esponding values Included 
in the classification request. This procedure is repeated 
for a sequence of rule memory entries until an ending 
condition is encountered, whereupon a padcet classifi- 
cation result is generated reflecting the result of the das- 
siTication operations. This result is provided to a padcet 
processor to take the appropriate action based on the 
ctassifk»tion result. 
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Description 

BACKGROUND OF THE INVENTION 

5 [0001] The present invention is related to the field of data connnnunication networks. 

[0002] In data conrvnunlcation networics, network devices such as switches are used to route packets through the 
network. Each switch typcally has a number of line interfaces, each connected to a different network segment. When 
a packet is received at a given line interface, forwarding logk; detennines which line interface the packet should be 
transmitted from, and the packet is transf en^ed to the appropriate outgoing line interface to be sent toward Its destination 

10 in the network. 

[0003] It is known to perfomr) packet filtering in network devices such as switches. Packet filtering can be used to 
achieve various network management goals, such as traffic monitoring and security goals. Filtering criteria are estab- 
lished by networic administrators, and provided to the switches or other devices that cany out the filtering operation. 
Packets received by the switches are examined to determine whether their characteristks match the criteria for any 

IS of the established filters. For packets that satisfy the criteria for one or more filters, predetermined actions associated 
with those filters are carried out. For example, under certain circumstances it may be desirable that packets originating 
from a given networic node be discarded rather than being forwarded in the network. A filter can be defined in whk:h 
the criterion is that a packet source address exactly match a specifk: value, which is the address of the node whose 
packets are to be discarded. The action assodated with the filter is the discarding of the packet When a packet Is 

20 received whose source address satisfies this criterion, it is cfecarded rather than being forwarded in the nonmal fashion. 
[0004] There are a number of different kinds of criteria that may be used to filter packets. These criteria include exact 
matches as well as range checking, i.e. , checking whether a value in a packet falls in some range of values. Numerous 
packet parameters can be used as criteria, such as source address, destination address, port klontif iers, type of service, 
and others. To be us^l, packet filtering processes must aikyw filters to be flexibly defined using different combinattons 

25 of these and other criteria. 

[OOOSl Because of this complexity inherent in packet filtering, it has traditionally been performed largely or exclusively 
in software within switches or other networic devk:es supporting packet filtering. Software-based filtering, however, 
presents a bottleneck when hk|h packet forwarding performance is required. Network administrators have had to make 
undesirable tradeoffs between networic responsiveness and network security, for example, because previous systems 

30 have not been capable of robust packet filtering at line rates. 

BRIEF SUMMARY OF THE INVENTION 

[0006] In accordancewlth thepresent invention, pack^ processing logk: in a networic devce is dedosed that provktes. 
35 hlgh-^)eed packet dassificatton for packet filtering purposes. The architecture of the dassification apparatus provkies 
substantial flexibility in the (iefinitk>n of complex filter criteria. Robust filtering can be perfonned at a suffciently high 
rate to avoki degracfing packet fonAfarding performance. 

[0007] The packet classification apparatus includes a rule ntemory and a criterion memory. One type of mle memory 
entry contains an operator and a pointer to a criterion memory entry. The operator defines a comparison operation to 

40 be performed, such as EQUAL (exact match) or LESS THAN. The criterion memory entry contains one or nnore values 
to be usedas comparands on one shte of the comparison, where conresponding values from a received packet appear 
on the other sicie of the comparison. For example, one comparand from criterion memory may represent a source 
address. This value is compared with the value appearing in the source ackJress field of received packets. 
[0008] Control logc responds to packet dassifnation requests to retrieve a rule memory entry from the rule memory, 

45 retrieve the criterion nnennory entry Mentified by the criterion memory pointer in the rule mennory entry, and perfomfi the 
operatbn specified by the operator in the rule memory entry on the values in the criterion memory entry and corre- 
spending values induded In the dasslficatton request. This procedure is repeated for a sequence of rule memory 
entries until a certain ending condition is encountered, whereupon a packet classification result is generated refieding 
the result of the dassification operations. This result is provided to a packet processor to take the appropriate action 

50 based on the dasslficatkm result- 

[0009] Other aspects, features, and advantages 6t the present invention are disdosed In the detailed description 
thatfolkyws. 

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING 

55 

[0010] Figure 1 is a bk)ck diagram of a networic switch incorporating a pack^ dassificatton engine in accordance 
with the present invention; 
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Figure 2 is a blocic diagram of a line interface in the network s witch of Figure 1 ; 
Figure 3 is a block diagram of a packet fonwarding engine on the line interface of Figure 2; 
Figure 4 is a block diagram of a packet header distributor applk»tl6n-specifk: Integrated circuit (ASIC) In the for- 
warding engine of Figure 3; 

5 Figure 5 is a btock diagram of a route and classlftoatlon engine In the packet header distributor ASIC of Figure 4; 

Figure 6 Is a diagram of the structure of a route and dasslfk^atlon request passed to the route and classlflcatbn 
engine of Figure 5; 

Figure 7 Is a diagram of the structure of a route and dassificat Ion result provided by the route and classlficatk>n 
engine of Rgure 5; 

10 Figure 8 is a diagram of the stmcture of a status Indcatlon provided by the route and classif iciation engine of Rgure 

5; 

Figure 9 is a block diagram of a packet dassifk:atton engine (P CE) in the route and classification engine of Figure 5; 
Rgure 10 is a diagram of the structure of entries in a mie memory in the packet dassification engine of Figure 9; 
Figure 11 is a diagram of the structure of entries in a first criteri on memory in the packet classifk^tion engine of 
15 Figure 9; 

Figure 12 is a diagram of the structure of entries In a second criterion memory In the packet dassification engine 
of Figure 9; 

Rgure 13 is a diagram of the structure of entries In a third criter Ion memory in the packet dassifk»tion engine of 
Figure 9; 

20 Figure 14 is a block diagram of a comparison k>gk: bkx:k for a b ank of criterion memory in the packet dassification 
engine of Rgure 9; 

Figure 15 is a block diagram of a conrtparator logc block used 1 n the comparison logic block of Figure 14; and 
Figure 16 is a diagram illustrating how packet filtering infomnatlon Is created, distributed, and used by different 
processing elements In the switch of Rgure 1 . 

25 

DETAILED DESCRIPTION OF THE INVENmON 



[0011] In Rgure 1 , a networtc switch 1 0 is shown as induding a number of line interfaces 1 2 conneded to respective 
networic segments 14. The line interfaces 12 are connected to a switch fabric 1 6 used to provide connecttons among 

30 the line interfaces 12 for pack^ fonwarding. The overall operation of the switch 1 0, including the dynamic configuration 
of the switch fabric 16, Is controlled by a switch control 18. In general, the various networtc segments 14 may be of 
different types. For example, certain of the networtc segments 14 may be optical links operating at any of a variety of 
standard signalling rates, such as OC-3/STM-1 and OC-12/STM-4. Others of the networtc segments 14 may be non- 
optteal links employing coaxial cable, for example, and carrying signals of different fomnats. 

35 [0012] Each line interface 12 is of course designed for operation with the spedfk: type of networic segment 14 to 
whk:h it connects. The prinnary tasks of each line interface 12 are to transfer packets or frames received from an 
attached nelworic segment 1 4 to another line interface 12 via the switch fabric 1 6 for forwarding on a networic segment 
14 attached to the other line interface 12, and to receive packets from the other tine Interfaces 12 via the switch fabric 
16 for fonwarding on the attached network segment 14. 

40 [0013] Rgure 2 shows the structure of one type of line Interiace 12. This interface contains four separate optk^al 
interface ports, each Induding physcal Input/output and framing drcuitry 20 and a forwarding engine 22. The fomvardlng 
engines 22 are all connected to switch fabric interiace logic 24, which interfaces with the switch fabric 1 6 of Figure 1 . 
The fonwarcfing engines also interface with a line Interface I/O processor (lOP) 26. Timing control logk: 28 and DC 
power drcuitry 30 are also inducied. 

45 [0014] Each fbnwarcfing engine 22 provMes a bidirecttonal data path between a connected physfeal I/O bk>ck 20 and 
the switch fabric interface 24. Received packets are segmented into multiple fixed-size ATM-like cells for transfer 
through the switch fabric 16 of Figure 1 to another line interface 12. Cells received fmm the switch fabric 16 via the 
switch fabric interface 24 are reassembled into packets for outgoing transfer to the connected physical I/O block 20. 
[0015] The lOP 26 is a generaH>urpose processor that performs background fundtons, i.e. functions that support 

50 the fonwarding of packets that are not carried out on a per-packet basis. One fundlon performed by the lOP 26 Is 
receh^ng packet fonNmnfing infomiatkm and packet filtering Information from the switch control 18 of Figure 1, and 
distril)uting the infbrmatkm to the forwarding engines 22. This process is described below. 

[0016] Rgure 3 shows a bkxrft diagram of a fonwarding engine 22. An inbound segmentation-and-reassembly (SAR) 
logn block 40 provkies a data path from a physk»l I/O block 20 to the switch fabric 1 6 of Rgure 2, and an outbound 
55 SAR k)g*c bkxrk 42 provkles a data path from the switch fabric 16 to the respective physical I/O block 20. Each SAR 
40, 42 is coupled to a respective control memory 44, 46 and packet memory 48, 50 used In perfomnlng the segnnentatton 
or reassembly functton. 

[0017] The SAR devfees 40 and 42 are both conneded to a packet header distributor (PHD) application-spedfk: 
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integrated circuit (ASIC) 52 via a 64-brt PCI bus 54. As described in more detail below, the PHD ASIC 52 provides 
FIFO queue interfaces betvveen the PCI bus 54 and a separate 64-brt bus 56. The bus 56 connects the PHD ASIC 52 
with a fonwarding processor (FP) 58 and fonvarding processor nr)emory 60. The PHD ASIC 52 is also connected to the 
lOP 26 of Rgure 2 by a separate bus 62. 

5 [0018] Figure 4 shows the structure of the PHD 52 of Rgure 3. A set of receive queues or RX queues 64 is used for 
temporary buffering of packet headers and other messages bound for the FP 58. As shown, there are four RX queues 
64, two queues for high^)riority traffic and two queues for lowijriority traffic. An example of high-priority traffic is traffic 
having a high Quality of Service (QOS) guarantee, such as a committed rate. Low-priority traff b is traffic having a tower 
QOS or no QOS guarantee, such as best-efforts. For each priority level, there is one queue (labeled '0") for traffic 

10 originating from the Inbound SAR 40, and another queue (labeled "1 ") for traffic originating from the outbound SAR 42. 
A set of transmit queues orTX queues 66 is used for temporary buffering of pacltet headers and other messages bound 
for the SARs 40, 42 from the FP 58. A route and classification engine 68 perfonDs a route lookup and various packet 
filtering checks on behalf of the FP 58. The packet filtering operation is described below. The route and classif k»tlon 
engine 68 receives status informatton from the queues 64, 66 via signal lines 69, and nnakes this informatton available 

15 to the FP 58 in a manner described bek)w. 

[0019] The overall operation of a fonwarding engine 22 will be described with reference to Figure 3 and Figure 4. 
Packets are received by the inbound SAR 40 from the associated physk:ai-layer circuitry 20 of Figure 2, and are stored 
in the packet memory 48. The inbound SAR 40 transfers the packet headera to an appropriate one of the RX queues 
64 in the PHD 52. The FP 58 polls the PHD 52 to determine queue status, and retrieves the packet headers from the 

20 RX queues 64 as appropriate. As part of the header processing, the FP 58 sends certain information elements from 
each header to the route and dassifcatton engine 68 in a route and classification request. The route and classif Nation 
engine 68 performs a route bokup and various packet filtering checks against the header elements in the request, and 
places the results of these checks Into a result queue (described below). The FP 58 obtains the route kx>kup and 
classifcatbn results from the result queue, and uses these results to create a new header for the packet. The new 

25 header is transferred back to the PHD 52 via one of the TX queues 66, along with information Identifying the Internal 
circuit on whbh the packet shouM be forwarded after segmentation. The inbound SAR 40 retrieves the new header, 
places it in the pack^ memory 48 with the paybad poribn of the received packet, segments the new packet and 
transfers the r^utting cells to the switch fabric 16 of Rgure 1 on the internal circuit specified by the FP 58. 
[0020] In the outbound direction, the outbound SAR 42 receives packets from the switch fabric 1 6 of Figure 1 , and 

30 reassembles these pack^ into the packet nnemory 50. Packet headera are sent to the PHD 52, and retrieved from 
the PHD 52 by the FP 58. For most packets, the route lookup and filtering checks will have already been performed 
during inbound processing, so these operatbns are not repeated. Some protocols, however, do require lookups and 
filtering for both inbound and ou1t>ound packets, and therefore these operatbns are optionally perfonned by the FP 58 
in conjunction with the route and dassifbatbn engine 68. If appropriate, the FP 58 formulates a new header for the 

35 packet, based in part on the Uentity of the internal drcult on which the segnnented outbound packet Is received. This 
new header is written to the PHD 52, along with transmit circuit information. The PHD 52 transfers the new header to 
the outbound SAR 42. The outbound SAR 42 places the new header in the packet memory 50 along with the packet 
paytoad, and transmits the packet to the assodated physbal layer interface 20 of Figure 2. 
[0021] Rgure 5 shows the structure of the route and dassifbatton engine 68. Requests from the FP 58 of Rgure 3 

40 are placed into a single request queue 70, and results are returned in a single result queue 72. Each queue 70 and 72 
hokte up to 16 requestAesult entries. A route bokup engine (RLE) 74 performs route lookups, typbally based on a 
destination address (DA) mduded in the header. A packet dassifbatbn engine (PCE) 76 perfom^ packet filtering 
checks, based on ^^edfied information included in the packet header. The operation of the PCE 76 is described in 
more detail bebw. Input RFO buffers 78 are placed between the request queue 70 and the RLE 74 and PCE 76, and 

^ output FIFO buffers 80 are placed between the RLE 74 and PCE 76 and the result queue 72. The FIFOs 78 and 80 
provide a measure of decoupfing between the processing periomned by the RLE 74 and the processing performed by 
the PCE 76. A multiplier 81 enabbs the FP 58 to read either the result queue 72, or status infomnation induding 
status from the request queue 70, the result queue 72, and the status appearing on the signal lines 69 of Rgure 4. The 
structure of these entries is described below. 

50 [0022] Rgure 6 shows the structure of the route and dasslfbatlon request that is passed to the PCE 76 and RLE 74 
via the request queue 70 of Rgure 5. The size of the request b four 64-blt words. The various fields are defined as 
folbws: 



FIELD NAME 


DESCRIPTION 


Type 


RLE Entry type: 0=Node, 1=Leaf 
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(continued) 



10 



15 



20 



25 



30 



35 



40 



45 



50 



55 



FIELD NAME 


DESCRIPTION 


Ind. 


RLE Indirect route: 
1=lndirect, 0=Direct 


Res. 


Unused reserved bit 


Order 


No. of DA bfts to add to RLE pointer 


RLEPtr. 


Base address of RLE entry to which DA is added (based on Order) 


PCERootO 


Starting address for PCE rule 0 


PCERootI 


Starting address for PCE rule 1 


0 


Set to zero, used for alignment cheddng 


Req. ID 


Request identifier, copied to result to enable matching with request 


IPTOS 


The contents of the Type of Service (TOS) field of the received packet 


IP Protocol 


The contents of the Protocol field of the received pack^ 


TCP Rags 


The contents of the TCP Flags field of the received packet 


IP Source Address 


The IP Source Address of the received packet 


IP Dest. Addr. 


The IP Destination Address of the received packet 


TCPAJDP Source Port 


The kJentifier of the TCP/UDP port on whk:h the packet was received 


TCP/UDP Dest Port 


The ktentifier of the TCPAJDP port for whk:h the received packet is destined 


Reserved 


Unused reserved bits 



[0023] As shown in the above table, there is a provisk>n for two separate sets of classif ication checks, one beginning 
at an address labeled "PCE Root 0" and the other as f>CE Root 1". The signiffcance of these separate starting ad- 
dresses is described below. 

[0024] As previously noted, the appropriate fields of the request are provkied to the respective input FIFOs 78 for 
the RLE 74 and PCE 78 of Rgure 5. Some of the fiekls, such as the Req. ID and the IP Dest. Addr., are provkied to 
both the RLE 74 and the PCE 76. Other fields are provided to only one or the other. The use of the fields routed to the 

PCE in partk^ular is described below. 

[0025] Rgure 7 and Rgure 8 show the respective ^ructures of the two different types of entries that are read from 
the route and dassifkation engine 68 of Figure 4. Rgure 7 shows a result entry, whch is obtained from the result queue 
72 of Rgure 5 and conveys the result of a dassificatkm search. Rgure 8 shows a status entry used to convey status 
information to the FP 58 of Figure 3. 

[0026] The fiekls of the result entry shown in Rgure 7 are defined as follows: 



RELDNAME 


DESCRIPTION 


T 


Type: 0 = PCE Result, t = PCE Status 


Req. ID 


Request Identifier (from tfte request) 


P 


PCE Match NOT Found: 

0 = Match Found, 1 = Match NOT Found 


1 


RLE Indirect Route: 
0 = Normal, 1 - Indirect 


L 


RLE Long Search: 0 = Short, 1 = Long 


E 


Error indicator 0 = Nomial, 1 = Error 


Z 


Zero padding 


R1-M 


Match in PCE Rooti (vaiki only if P 0): 0 = Match in root 0, 1 = Match in root 1 


Depth 


Depth of route lookup search 
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(continued) 



FIELDNAME 


DESCRIPTION 


PCE Match Addr. 


Address of last rule checked In PCE 


RLE Rags 


Flags from RLE table entry 


RLE Next Hop Ptr. 


Pointer from RLE table entry 



w 



15 



20 



[0027] The fields of the status entry shown in Figure 8 are defined as follows: 



FIELD NAME 


DESCRIPTION 


Zero 


Unused, set to zero 


TX Message 


Remaining space in foniwarding-processor-to-lOP message queue 


RCE Results 


Number of pending entries in result queue 72. Nonnally zero, because status Inserted only when 
queue is empty. 


RCE Requests 


Number of empty entries in request queue 70 


Tx-0 


1 Number of empty entries 


Tx-1 


J in TX queues 66. 


Hi-0 


1 


Hi-1 


1 Number of empty entries in 


Lo-0 


1 RX queues 64. 


Lo-1 


J 



30 



40 



45 



[0028] The general operation of the route and classification engine 68 will be described with reference to Figure 5 
through Figure 8. The FP 58 of Figure 3 writes lool(up and classification requests to the request queue 70. When a 
request reaches the front of the request queue 70, different information elements from the request are written simul- 
taneously into the respecthre input FIFOs 78 for the RLE 74 and the PCE 76. The RLE 74 and PCE 76 operate on the 
separate pieces of each request Independently and in general finish their respective processing operations for a given 
request at different times. The results of these operi^ons are written to the output FIFOs 80. When both sets of results 
for a given packet have reached the front of the output RFOs 80, a single combined result is written to the result queue 
72. The combined results are read by the FP 58 and used to fomiulate new packet headers and circuit information for 
the SARs 40 and 42 of Figure 3, as discussed above. 

[0029] More partknilariy, the FP 68 uses the route and classification engine 68 In a batch fashion. When there is 
sufficient room in the request queue 70. a bur^ of requests are 

1 .4 result entries 

2.3 result entries folk>wed by 1 status entry 
3.2 result entries fbltowed by 2 status entries 
4.1 result entry followed by 3 

5.4 status entries 



50 



55 



[0030] The FP 58 will generally issue read commands until the result queue 72 is empty, whk:h is inferred whenever 
one or more ^atus entries are included in the result block. The FP 58 then uses these results while the route and 
classifcation engine 68 processes the next batch of requests. The FP 58 uses the status information to manage the 
flow of requests, so that the RLE 74 and PCE 76 are kept busy and the queues 70 and 72 and FIFOs 78 and 80 are 
prevented from overflowing. 

[0031] It will be noted that in the illustrated embodiment, there is only one status entry that can be read, and the 
multiple status entries in a result block represent multiple reads (rf this single entry. In altemative embodiments it may 
be useful to provkle additk>nal, lower-priority information in the second through fourth status entries, for example for 
statistks gathering purposes or other background processing. 

[0032] One signiffcant advantage of appending status infomnation to results is improved effteiency in using the FP 
bus 56. Whenever the FP 58 issues a read for results, either useful results or useful status information is returned. 
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Additionally, the result block is returned in burst fashion, so that overhead associated with reading is reduced. Also, 
the FP 58 obtains infonnation about the queues around the RLE 74 and PCE 76, and about the RX queues 64 and TX 
queues 66. in a single read transaction. 

[0033] Figure 9 shows the structure of the PCE 76 of Rgure 5. Data representing filters and bindings (discussed 
5 below) are stored in a rule nnennory (RM) 82 and a criterion mennory (CM) 84. The CM 84 Includes three commonly 
addressed menrK)ries CMO 86, CM1 88 and CM2 90. Three comparison logic blocks 92, 94 and 96 are associated with 
respective ones of the criterion memories 86, 88 and 90. Addressing and control logic 98 decodes requests received 
from the request queue 70 of Figure 5. generates addresses for the RM 82 and the CM 84, sequences through multiple 
rules as required by each request, and generates results that are passed back to the result queue 72 of Figure 5. The 
10 addressing and control logk: 98 also Interfaces to the lOP 26 of Figure 2 to enable the reading and writing of the RM 
82 and CM 84 by the lOP 26. Bus transceivers 1 00 provide the necessary data path between the lOP 26 and the RM 
82 and CM 84. An AND gate 102 provides a single MATCH signal when con-esponding MATCHn outputs from the 
comparison k)gtc bk)cks 92, 94 and 96 are all true. 

[0034] Rule sets for packet filtering are typnally originated by a Network Management Station (NMS), but can also 
15 be dynaiTrically assigned by the FP 58 based on identified fk>ws. Part or all of the following Information is provided by 

the NMS or FP 58 for filters: IP Destination Address with mask; IP Source Address with mask; IP protocol identifier; 

TCP/UDP Source Port and Destination Port identifiers; IP Type of Service kJentifier and mask, and miscellaneous flags. 

The various information elenrients from a filter are conopared with corresponding elements from each received packet 

in order to detemrune wh^er the packet matches the filter criteria. If so, some specify action for the filter is taken, 
20 such as intentionally discarding a packet. If not, some default action is typically taken, such as allowing the packet to 

proceed toward Its destination. 

[0035] Tradittonally, packet fitters are represented as an ordered list of comparison sets that are searched linearly. 
In the PCE 76, the filter elements are divided into criteria-(the comparison values) and rules (the list Itself and the 
operators to be used for each comparison). This separation of rules and criteria is reflected In the use of separate rule 
25 memory (RM) 82 and criterton memory (CM) 84. The mennorfes 82 and 84 are separately optimized for their respective 
functbns, thus enhancing effctency and performance. Also, entries within tiie CM 84 can bo referred to by multiple 
rules in the RM 82, further enhancing storage efficiency. 

[(N)36] The RM 82 contains an array of rule memory entries, each of which may be one of two types. A first type 
contains a set of operators and a pointer to a row of CM 84 that stores comparands for a corresponding filter. A second 

30 typecontains a pointer to another rule memory entry. These entries are used to perfomn jumps between non-contiguous 
Also, entries witiiin the CM 84 can be referred to by multiple rules in the RM 82, further enhancing storage efficiency. 
[0037] The PM BZ contains an array of rule memory entries, each of which may be one of two types. A first type 
contains a set of operators and a pointer to a row of CM 84 that stores comparands for a corresponding filter. A second 
type contains a pointer to another rule ntemory entry. These entries are used to perform jumps between non-contiguous 

35 segments in a set of rules being searched sequentially. In the illustrated embodiment, the RM 82 can contain up to 
16K entries. 

[0038] The CM 84 is segmented into three separate memories CMO 86, CM1 88 and CM2 90, each of which can 
contain up to 4K entries in the illustrated embodiment The organization of the CM 84 exploits a hierarchy that is inherent 
in IP packet classification. Because filtering on certain fiekte is usually accompanied by filtering based on other fields 

^ as well, it is reasonable to restrict whch fiekis are stored in the separate memories CMO CM1 , and CM2. These 
restrictions further enhance storage efficiency. The most comnr>only filtered fields. Source Address and Destinatk>n 
Address, are supported in all three memories CMO 86, CM1 88 and CM2 90. As described below, other fields are 
supported only in CM1 88 and/or CM2 90. This architecture maximizes the fiexibility with whteh space in the CM 84 
can be allocated, whfle at the same time enabling powerful parallel searches. The structure and use of CM 84 are 

^ descrft)ed In nnore detail below. 

[0039] Figure 10 shows the structure of the entries in the RM 82 of Figure 9, whk:h are also refen^ed to as rule memory 
entries. Each 39-bil entry has a 1-blt Type field. If this field is 1 , then bits 1 3-0 of the entry contain a pointer to another 
locatfon in tiie RM 82, i.e., a pointer to another rule memory entry. If this field is 0, the entry contains infonmatton for 
performing a filter check. In this case, bits 11-0 contain an address of a row of CM 84 where operands for the check 

50 are to be found, and bits 35-12 contain encodings of operations to be performed on respective operands and fields 
from the request These operations are descrft>ed in more detail betow. Bit 36 is a Carry bit used to form compound 
rules, for example to perfonrn range checking. If the carry bit is zero, the rule is evaluated by itself. If the carry bit is 
one, tiie rule evaluates as true only if the next mie also evaluates as true. Bit 37 is a Done bit indteating that tiie last 
of a string of rules to be checked as part of a request has been reached. 

55 [0040] The criterion operator fieU contains eight 3-bit logcal operator codes. Each operator code specifies an op- 
eratton to be performed on corresponding connparands selected from the request and the criterion memory entry. The 
fields of the criterion meaK>ry entry are described betow. The assignment of criterion operator bits to comparands is 
as follows: 
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35-33 


CMOSA/DA field 


32-30 


CM1 Protocol field 


29-27 


CM1 Source Port field 


26-24 


CM1 SA/DAorDPfieki 


23-21 


CM2 Protocol field 


20-18 


CM2 TOS or TOS with mask field 


17-15 


CM2 Source port or Flags with mask field 


14-12 


CM2 SA/DA or SP or DP field 



[0041 ] The operator code specifies a comparison to be performed, where the comparand from the request is on the 
left of the operator and the comparand from the criterion rnemory entry is on the right. For example, if the operator is 
">*, then the expression evaluated Is (request dala > criterion data). The operator codes are as follows: 



25 . 



000 


Greater than 


001 


Less than 


010 


Equal 


oil 


Not Equal 


1XX 


Dort*t care (i.e. force TRUE regardless of comparand values) 



[0042] The criterion operators are used to configure k>gic within the comparison logk: blocks 92, 94, and 96 in a 
manner described below. 

[0043] Figure 11 shows the structure of the entries in CMO 86 of Figure 9. Each entry is 38 bits wide. A single bit, 
bit 37, is used to di^'nguish between two possit>le corrfigurations for the entry, as either a 32-bit source address (SA) 
or a 32-bit destination address (DA). Bits 31-0 contain an SA or DA value as required by a corresponding filter. Bits 
36-32 contain a 5-bit encoded mask value that is used to limit the extent of the comparison between the SA/DA in the 
entry and the SA/DA of the request The use of the mask is described in more detail below. 
[0044] Rgure12showsthestructureoftheentriesin CMt 88 of Figure 9. Each entry is 47 bits wkte. Four different 
configurations are possible, as indfeated by bits 46-45. The PTCL f ieki identifies an IP protocol in all four configurations. 
The 1 6-bit SP and DP fields in configurations 2 and 3 represent source port and destination port identifiers, respectively. 
The contents of bits 36-32 are undefined in configuratiorts 2 and 3. 

[0045] Figure 13 shows the structure of the entries in CM2 90 of Rgure 9. Each entry is 51 bits wide. Eight different 
configurattons are possible, as indwaled by bits 50-48. The TOS field of configurations 2 through 7 klentifies an IP 
Type of Servk». In configuratmns 3 through 7, the TOS Mask field contains an 8-blt mask used to limit the extent of 
the TOS comparison, as descrit>ed below. The S-bit FI^GS fiekl contains flag values to be compared against corre- 
sponding fiag bits from TCPAJDP packets. The 8-bit FLGS IMSK field is used to limit the extent of the FluAGS compar- 
ison, as described below. 

p)046] Figure 14 shows the general structure of the comparison k>gte blocks 92, 94 -and 96. Two or more bk)cks of 
comparator k>gic 104-1,... 104-n are used to perform nrujttiple comparisons in parallel, where each connparison is be- 
tween a given field of a reque^ and a corre^ndingfiekl of a criterion menrwry entry. In the comparison logic 92 for 
CMO 86, for example, two comparator logk: blocks 1 04 are employed, one for the Source Address field of the request 
and one for the Destination Address fieW of the request. The comparison logk: 94 for CM1 88 contains comparator 
logc blocks 104 for Source Address, Destination Address, IP Protocol, Source Port and Destinatk>n Port. The com- 
parison k)gk: 96 for CM2 90 contains comparator bgk: blocks 104 for Source Address, Destination Address, IP Protocol, 
Source Port, Destination Port, Type of Servce without mask, Type of Servk^e with mask, and Flags. 
[0047] The outputs from the comparator iogtc blocks 104 Include indk^ations for NOT EQUAL (#), EQUAL (=), LESS 
THAN (<) and GREATER THAN (>). These signals are provkted to the inputs of respective selectors 1 06-1 .... 1 06-n, 
along with a k>gk: 1" which Is used to implement a DONT CARE function. The selectors 106 receive the operators 
from an operator-type rule memory entry as control inputs. These operators reskle within bits 35-1 2 of the rule memory 
entry, as described above. 

[0048] The respective outputs of the selectors 1 06 are provided to another selector 1 08, whk^h selects from among 
different combinations of the outputs of the selectors 106 based on the configuration bits fi-om the criterion memory 
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entry. For example, in the connparison logic 92 for CMO, the configuration selector 1 08 selects between a SA comparison 
result and a DA conrtparison result based on the value of bit 37 of the criterion memory entry. The configuration selectors 
108 in the other comparison logic blocks 94 and 96 operate similariy. The output signal MATCH from the configuration 
selector 108 indicates whether the data in the request satisfies the criteria from the respective criterion memory 86, 
5 88 or 90. As shown in Rgure 9, the MATCH outputs from the comparison blocl<s 92, 94 and 96 are ANDed together 
by an AND gate 10, to provide a single MATCH indication to the addressing and control logic 98 for controlling the 
classlTication operation. 

[0049] Figure 15 shows the general structure of a comparator logic block 1 04. An EQUAL comparator 1 1 0 determines 
whether two comparands are equal, a LESS THAN comparator 1 1 2 determines whether one of the comparands is less 
10 than the other comparand, and a GREATER THAN comparator 114 determines whether the one comparand is greater 
than the other comparand. The output from the EQUAL conrtparator 110 Is Inverted by an inverter 116 to obtain the 
NOT EQUAL indk:ation. 

[0050] The inputs to each comparator 110, 112, and 114 are a comparand from the CM 84 (shown as "CM com- 
parandT) and a possibly masked comparand from the request (shown as REQ comparand). Masking logic is used for 

IS those fiekte having associated masks. AND gates 118 innplement bit-by-bft masking. The multi-brt mask (shown as 
'CM mask") may be used directly, as in the case of the Flags Mask, or it may be decoded or expanded by expander 
logk: 120, as in the case of the SA/DA Mask. The expander togic 120 generates a 32-brt value having zeroes in a 
number of trailing bit positions as indcated by the 5-bit encoded mask value, and ones elsewhere. For example, if the 
mask value is 01011 binary, which is equhralent to 11 dedoial, the decoded nfiask is FFFFF800 hexadednnal, whk:h 

^ has ones in the leading 21 positions and zeros in the trailing 11 positions. This mask indicates that only the most 
stgnifk»nt 21 bits of the SA/DA shouM affect the comparison result. 

[0051] The operation of the packet classifcation engine (PCE) 76 proceeds generally as follows: 

1 . The RM 82 and the CM 84 are initialized by the lOP 26 of Figure 2. This happens at power-up, and during 
25 operation efther by dynamk: assignnnent or by a Networic Management Statk>n (NMS) (discussed below). 

2. A packet classification request submitted by the FP 58 is retrieved from the request queue 70 of Figure 5. 

3. The RM 82 is indexed by the contents of the root 0 address of the request to retrieve the first rule memory entry 
of the search. If the entry is a pointer type, then this step is repeated for the rule memory address in the retrieved 
entry. It is possible for this step to repeal multiple times. 

30 4. If the retrieved rule memory entry is an operator type, then a criterion nrtemory entry is retrieved at the location 
specified by the CM address in the rule menriory entry. Selected comparands from the CM 84 are compared with 
corresponding fields of the request, according to the operator In the rule memory entry. Various fields may be 
masked as described above. 

5. The rule memory address increments by one until either an entry having a DONE bit set to one is reached, or 
35 a match condition Is found (i.e. the result of the comparison operation is TRUE). A rule may have its CARRY bit 

set, whk:h requires that the next rule also evaluate as TRUE before a match is declared. 

6. If any rule nnemory entry encountered in the search is a pointer type of entry, it points to another rule mennory 
entry rather than to a criterion memory entry. In this case, sequential rule evaluation continues beginning at the 
pointecKo rule memory entry. 

40 7. The above process is performed once beginning at the root 0 address in the request. If DONE Is reached for 
the filters associated with root 0, then the process is repeated beginning at the root 1 address. When a match is 
found, the result indicates whether it has been fburKi using root 0 or root 1 rules. 

8. When the search temninates, either by encountering a match or by encountering DONE in the root 1 search, a 
result is written back to the result queue 72 indk»ting tiie results of the filtering check. The result contains the 
45 address of the last rule checked, and whether or not a match has been found. If a match has been found, the 
address is used by the FP 58 to index Into an action table, whk;h initiates an action appropriate to the result. For 
example, if the match is for a rule indk»ting that all packets having a DA of less than a certain value should be 
dropped, then the actk>n table points to a routine that causes the packet to be intentionally discarded. 

50 [0052] As described above, the CM 84 can be used in a variety of different configurations. Each of the three menrraries 
CMO 86, CM1 88 and CM2 90 can be used In different modes to realize the different configurations. The following truth 
table presents the different comparisons that can be performed using the different configuration modes of the criteria 
memories 86, 88 and 90. A '1* lndk:ates that a comparison can be performed using a given configuration mode, and 
a "0* indx:ates that the comparison cannot be performed. 

55 
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(continued) 



5 



10 



15 



20 



CNRG 


SAftMask 


DA & Mask 


PTCL 


SP 


DP 


TOS 


TOS & Mask 


FLAG & Mask 


CMO-1 


0 


1 


0 


0 


0 


0 


0 


0 


CM1-0 


1 


0 




0 


0 


0 


0 


0 


CM 1-1 


0 


1 




0 


0 


0 


0 


0 


CM1-2 


0 


0 




1 


1 


0 


0 


0 


CM1-3 


0 


0 




1 


1 


0 


0 


0 


CM2-0 


1 


0 




0 


0 


0 


0 


0 


CM2-1 


0 


1 




0 


0 


0 


0 


0 


CM2-2 


0 


0 




1 


1 




0 


0 


CM2^ 


0 


0 


0 


1 


1 




1 


0 


CM2-4 


0 


0 


0 


0 


1 




1 


1 


CM2^ 


0 


0 


0 


1 


0 




1 


1 


CM2-6 


0 


0 


0 


1 


0 




1 


1 


CM2-7 


0 


0 


0 


1 


0 




1 


1 



[0053] Thus for example, an SA comparison can be perfomrted using any of CM(W), CM1 -0, and CM2-0. A Fl_AGS 
25 comparison can be performed using any of CM2-4 through CM2-7. The ability to perfomi a given comparison using 
any of a variety of configuration modes provides desirable flexibility In organizing CM 84, which in tum enhances 
efficiency. The alk)cation of criterion memory space is described in some detail below. 

[0054] it may be possible in alternative embodiments to achieve greater storage efficiency by using different methods 
of encoding the criterion memory configuration information, it will be noted that in the illustrated embodiment, 30 bits 

30 are used to store the configuratkm menK>ry for each criterion memory entry. These 30 bits Include 24 bits of operator 
codes In a rule memory entry, 1 bft in a CMO entry, 2 bits in a CM 1 entry, and 3 bits in a CM2 entry. This scheme 
simplifies decoding within CMO, CMt and CM2. However, It can be shown that the number of all possible configurattons 
of oomparands and operations for a criterion memory entry is on the order of 3.3 x 10®, and can thus be represented 
using only 22 bits. Thus it may be possible, for example, to use a single 22 bit configuratton field in each rule memory 

35 entry, from whk^h the operator and comparand Infomnatton Is decoded. However, the decoding required in such em- 
bocfiments are generally more cbmplnated than in the Illustrated embodiment, due to the lack of one-to-one corre- 
spondence between each configuratkm bit and a respective section of CM84. 

[0055] Rgure 1 6 shows the manner in which packet filtering information is managed and utilized in the switch 1 0 of 
Figure 1 . Generally, the source of packet filtering infomnation is a networic management station (NMS), whk:h is typk:ally 

40 located apart from the switch 10 of Figure 1 . The NMS commun»ates with a central processor (CP) resicfing within the 
switch control 18 of F'^re 1 using a networic management protocol such as Simple Networtc Management Protocol 
(SNMP). The CP recedes the filtering infomiation from the NMS, and is responsible for distributing it to the lOP 26 of 
each line Interiace 12. Additionally, the CP maintains the infomiation in non-votatile (NV) storage, so that the switeh 
10 is able to operate during periods when the NMS may be unavailable. 

45 [0056] The fitter informatmn sent from the CP to the lOP 26 Includes (1 ) fitters, each of whk^ specifies up to a small 
number of criteria that can be applied to received packets, (2) bindings, that is, infonnation associating different groups 
of the filters with different ports and/or circuits in the switch 1 0, and (3) actions, having associations with the filters, 
whk:h are to be performed when filter criteria are satisfied. 

[0057] In operation, when an lOP 26 is initialized, the CP retrieves an existing filtering table and binding database 
50 from the NV storage and downkwds them to the lOP 25 oH each line interface 12. When the NMS adds, deletes or 
modifies a filter or binding, It issues an SNMP actkm request to pass the new Infonnation to the CP In tum, the CP 
posts the change to each lOP 26. 

[0058] The lOP 26 receives the filtering information fi^om the CP and instantiates local copies of the filters, bindings 
and act»ns into its memory. The lOP 26 updates these local copies whenever the CP sends new infonnation. The lOP 
55 26 programs the FP memory 60 in each fon¥arding engine 22 of Rgure 2 with a table of different acttons that can be 
takenforthe various feters.ThelOP 26 also creates RM entries and CM entries con^esponding to thefilters and bindings, 
and programs the RM 82 and CM 84 (Rgure 9) of the PCE 76 (Figure 5) with these entries. Whenever the lOP 26 
receh^ new filtering iriformatton from the CP, RM and CM entries are deleted, added, or changed as necessary. 
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[0059] The FP 58 is responsOble for processing pacltets with the assistance of the PCE 76. Using the information 
provided by the lOP 26, the FP 58 maps the port and circuit identities of each received packet into root 0 and root 1 
addresses, creates a PCE request using these addresses, and writes the request to the PCE 76 via the request queue 
70 (Figure 5). As mentioned above, the FP 58 generally attempts to operate the PCE 76 in a batch fashion by writing 

s a burst cK multiple requests if possible. The PCE processes the requests in the manner described above. The FP 58 
polls the PCE 76 to obtain results, which are returned by the PCE 76 in blocks as described above. For each result in 
whk^h a match is indicated, the PCE match address from the result is used as an index into the action table established 
by the lOP 26 to ascertain whk^h action to take for the packet. The FP 58 then perfomns the indcated action. 
[0060] As previously menttoned. both the RM 82 and the CM 84 are relatively small memories implemented on a 

10 single IC in order to achieve high performance. It is important that the limited space in these memories be efficiently 
managed. The lOP 26 is responsible for the allocation of space In the CM 84 for filter criteria, and the allocation of 
space in the RM 82 for rule sets. These operations are described in turn below. 

[0061] Filters may be one of two types, either stand-alone or compound. Stand-ak>ne filters can be realized using 
only one rule. Compound filters require multiple rules. Although there can be different types of compound filters, the 
15 only compound filters employed in the illustrated embodiment are range filters. A range filter requires one rule to check 
for an upper bound of a range and another rule to check for a lower bound of the range. Thus, the first step in adding 
a fitter is to determine whether the filter is a standalone filter or a range filter. If the filter is a standalone filter, only one 
criterion memory configuration is required, whereas two configurations are required for range fitters. The contents of 
CM 84 are then searched and/or evaluated to determine how to best represent the filter in the CM 84. Once a conflg- 
uratton is chosen, the fitter informatkm is added as an update to the CM 84. These processes are described in more 
detail bek>w. 

[0062] There are many types of conftguratrons of a criterion memory entry that can be used to realize a given fitter. 
These are organized into seven CM configurations depending on whk^h of the criterion memories 86, 88 and 90 are 
used. The foltowing table shows several of the nnore comnrtonly used configuration types, arranged according to CM 
^ configuration: 





TYPE 


CIMCONRG 


CMO IMODE 


CM1 MODE 


CM2MODE 




6 


(CM0,CM1,CM2) 


0:SA 


1:DA 


2:PTCL.SP.DP,TOS 


30 


5.1 

5^2 
5_3 


(CM1,CM2) 




0:SA 
1:DA 
0:SA 


2:PTCL,SP,DP,TOS 
2:PTCL,SP,DP,TOS 
1:DA,PTCL 


35 


4_t 
4^2 
4_3 


(CM0,CM2) 


0:SA 
t:DA 
Q:SA 




2:PTCL,SP,DP,TOS 
2:PTCL,SP,DP,TOS 
1:DA.PTCL 


40 


3_1 
3-2 
3_3 


(CM0.CM1) 


0:SA 
1:DA 
0:SA 


2:PTCL,SP,DP 
2:PTCL,SP.DP 
1:DA.PTCL 






2_1 
22 
2.3 


(CM2) 






0:SA,PTCL 
1:DA,PTCL 

2:PTCL,SP,DP,TOS 


45 


1_1 
1^2 
1-3 


(CM1) 




0:SA.PTCL 
1:DA,PTCL 
2:PTCL,SP,DP 




50 


0_1 
0.2 


(CMO) 


0:SA 
1-DA 







[0063] The CM configuratkms are ranked from most expensive to least expensive in terms of resource consumption. 
For many filters, any of a variety ol configurations may be used, but the goal is to use the least expensive, or 'minimum', 
configuration in order to maxinize the dfk:tency of memory use. For exanrtple, a filter needing only an (SA, SA Mask) 
comparison can be implemented using any CM configuration, and the minimum configuration is (CMO). As another 
example, a filter neecfing (SA, SP, and PTCL) can be implemented using any of the four configurations (CM0,CM1), 
(CM0,CM2), (CM1, CM2), and (CMO, CM1, CM2); the minimum configuration is (CMO, CM1). 
[0064] The minimum configuration Is used as the starting point in a search for the minimum available configuration. 
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If the minimum configuration is available, then it is used. Othenvise, configurations that are successively more expen- 
sive are considered until an available one is found. In the above example, the configurations are searched in the 
following order (CMO, CM1), (CMO, CM2), (CM1, CM2). and (CMO. CM1. CM2).The configuration search employs a 
collection of linked lists of free criterion memory loc^ons, wherein each list represents a particular set of free columns 

5 in a single row, e.g. (CMO), (CMO, CM1), etc. Based on the type of comparisons required by the filter, the lOP 26 
searches all eligible lists in a predetermined sequence looking for the first one with an available entry. 
[0065] If the selected criterion memory configuratton is larger than the minimum required configuration for a given 
filter, then the renrminder portion is made available for use by otherfilters. Thus in the above example, if the configuration 
(CMO, CM1 , CM2) is used when only (CM0,CM1)is required, then one unit of (CM2) is made available for use by other 

10 filters. 

[0066] Once a configuration has been chosen, the various elements of the filters are allocated to the different sections 
of CM 84 as appropriate. Continuing with the example of a filter requiring (SA, SP, and PTCL). and assuming that the 
configuration (CM0,CM1)is chosen, then the SA and the SA Mask are allocated to CMO, and the SP and PTCL are 
allocatedtoCMI. This allocation corresponds to theconf^rationtype3_1 from the above table. CMO 86 is configured 

15 in mode 0, and CM1 88 is configured in mode 2. Once this allocation is complete, the entry (or entries for range filters) 
for CM 84 are generated (see Rgure 11 - Rgure 13 and accompanying description). Also, the data for the criterion 
operators (bits 35-12) for a con^esponding rule menriory entry (see Figure 10 and accompanying description) are also 
generated. The rest of the rule memory entry is generated during filter binding, discussed below. 
[0067] When a filter is deleted, the CM configuration used for the deleted filter is made available for re-use. Available 

20 configurations are concatenated if possible to make larger configurations. These can be used later in whole or in part 
as descn'bed above. For example, if a unit of(CMO) is freed by deletion of a filter, and a unit of(CM1 ) is available In the 
same row of CM 84, then a unit of (CMO, CM1) is created. 

[0068] As previously menttoned, the lOP 26 is also responsible for maintaining rule sets that represent "bindings" of 
filters, or assodattons between s^ of one or more filters with logcal ports or circuits. This process Involves the alto- 

25 catton and programming of the RM 82. When a binding is to be added, the size of the binding to be added is first 
evaluated. The size is dictated by the number of fBters used with the logical port or circuit, and the mixture of range 
filters and non-range filters. Once the size of the binding is known, space in the RM 82 is allocated. In the illustrated 
embodiment, rule nrtemory space is allocated in segments whose sizes are powers of two. Free segments are main- 
tained on respective free lists until allocated to a binding, and segments from deleted bindings are returned to the free 

30 lists for re-use. The segments are chained together using singly linked lists. For example, each free list is a singly 
linked list of non-alkx»ted segments of the same size. Each binding is a singly linked list of generally different-size 
segments. 

[0069] Conskler a binding requiring 2t mie nrtemory entries. For this binding, segments of sizes 16, 4, 2 and 2 are 
preferably alk)cated. The 16-entry segment stores 15 rules and a pointer to the 4-entry segment. The 4-entry segment 
35 stores three rules and a pointer to one of the 2-entry segments. whk:h In turn stores one rule and a pointer to the other 
2-entry segment. The last segment ^ores two rules. During allocation, if a segment of a desired size is not available, 
a larger segment is utilized. Unused space in a segment can simply remain unused, or attematively can be made 
available for alkx»tion to other bindings, in a manner similar to that discussed above for allocation of criterion memory 
configurations. 

40 [0070] Once the memory aUocation is complete, the entries for the RM 82 are created and written into the RM 82. 
During this process, each operator type rule is programmed with the address of the con^esponding criterion memory 
entry that shouM be used with the rule, and the operators are programmed with appropriate values based on the filter 
represented by the rule/briteria pair. The rules are an^nged in logfcal sequence In the RM 82 in accordance with the 
desired sequence in whk:h the filters should bechecked. Within a segment of RM 82, the rules are arranged sequentially. 

45 For bindings spanning multiple segnnents, the segnnents are chained together such that the rules are evaluated in the 
desired sequence. 

[0071] Various apparatus and methods related to packet classificatton have been described. Although the present 
invention has been described primarily with reference to Internet Protocol (IP) packets or messages, it will be apparent 
that the technk^ues described may be used for other types of messages. It will also be apparent to those skilled in the 
50 an that other modificatk)ns to and variatk>ns of the above^tescribed technique are possible. 
Accordingly, the invention shouM be viewed as limited solely by the appended claims. 



Ctaims 

55 

1 . Packet classification apparatus, comprising: 

input interface logx: operative to receive a packet classif bation request including information from a packet 



12 



EP1 128609 A2 



being processed by. a packet classification requestor; 

a rule memory operative to store rule memory entries, each rule mennory entry containing an operator and a 
criterion memory pointer, 

a criterion memory operative to store criterion mennory entries, each criterion memory entry containing a cri- 
terion; 

output interface logic operative to provide a packet classification result to the packet classrf k»tlon requestor; 
and 

control logk: operative in response to the received packet dassifcation request to: 
(t) retrieve a rule memory entry from the rule memory; 

(ii) retrieve a criterion memory entry from the criterion memory at a locatbn specified by the criterion 
memory pointer in the retrieved rule memory entry; 

(Hi) perform an operation specified by the operator in the retrieved rule mennory entry, the operation being 
carried out on the packet inforniatk>n from the packet classifk»tk>n request and the criterion from the 
retrieved criterion memory entry; and 

(Iv) generate a packet dassificatbn result reflecting the result of perfomning the operation. 

2. Pack^ dassifc^on apparatus according to claim 1 , wherein: 

the rule memory Is operative to store both first-type and second-type rule memory entries, each first-type rule 
memory entry containing an operator and a criterion memory pointer, and each second-type rule memory entry 
containing a rule memory pointer; and 

the control U)gc Is operative in response to the received packet dassifk^ition request to: 

(I) determine whether the retrieved rule nnennory entry Is a first-type entry or a second^e entry; 

(ii) retrieve the criterion memory entry and perform the specified operatk)n If the retrieved rule memory 
entry is a first-type entry; 

(iii) if the retrieved mle menrK>ry entry is a second-type entry, then retrieve another rule memory entry at 
a kx:atk>n specified by the rule memory poiriter contained In tiie second-type entry, and repeat the pre- 
ceding steps for the newly retrieved rule memory entry; and 

(iv) generate a packet dassifk:atk>n result reflecting the results of perfomiing the respective operattons 
specified by all retrieved first-type entries. 

3. Pack^ dasslf k»tk)n apparatus according to daim t , wherein the control logic is further operative to repeat ^eps 
(l)-(ill)for additional rule memory entries until an indfeatton of completion is reached. 

4. Packet dassmcation apparatus according to daim 3, wherein the indication of completion Is an asserted DONE 
bit in a relieved rule memory entryL 

5. Packet dassmcaaSon apparatus according to daim 3, wherein the lndk»tk>n of completion is the satisfadk>n of a 
condition specified by the operator In a retrieved rule memory entry. 

6. Packet dasslfk»tion apparatus according to daim 3, wherein the addlttonal rule memory entries are retrieved by 
sequentially accessing successive kx;atk)ns In the rule memory. 

7. Packet classification apparatus according to daim 3, wherein the additional rule memory entries are reeved by 
accessing tocations spa:lfied in rule mennory pointers contained in retrieved rule memory entries. 

8. Packet dassifcation apparatus according to daim 1, wherein the control logk: is operative to retrieve the rule 
memory entry based on a nile memory address induded In tiie received packet dassif Ication request. 

9. Packet dassifcation apparatus according to daim 1 , wherein the rule nnemory entry retrieved by the control logk: 
is a first rule mennory entry, tiie control togfc being operative to select the first rule memory entry based on a first 
njle memory address Indudied In the received packet classification request, and wherein the control logc is further 
operative to seled a second rule nnemory entry based on a second rule memory address also included In the 
received packet dassifk^tton request, and to repeat steps (i)-(iil) for the second rule memory entry. 

10. Packet dassifcation apparatus according to daim 1 , wherein the rule memory entry contains a CARRY indteator 
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indicating whether the rule memory entry is a first rule memory entry forming a compound rule with a second rule 
menrK)ry entry, and wherein the control logic is operative to repeat steps (i) - (iii) for the second rule memory entry 
and to generate the packet dassrfication result in step (Iv) such that the packet classification result reflects the 
results of the operattons for both the first and second mle memory entries. 

5 

11. Packet classification apparatus according to daim 1, wherein the criterion in the criterion memory entry and the 
information in the request are network addresses. 

12. Packet classifk:atlon apparatus according to daim 11 , wherein the addresses are destinatton addresses. 

10 

13. Packet dassiffcation apparatus according to daim 1 , wherein each criterion memory entry contains configuration 
Infomnation indnating a manner in which the criterion memory entry is configured, and the control logk: is operative 
to (i) interpret the configuratk>n infomiatton of the retrieved criterion memory entry to detennine which of multiple 
fields in the criterion memory entry are to be used in the operation, and (ii) perfomi the operation using only the 

15 appropriate fields of the criterion menwry and corresponding infomnation from the packet classifteation request 
based on the determined configuration. 

14. Packet dassifcation apparatus according to daim 1 , wherein each criterion memory entry contains configuratk>n 
Information indicating a manner in whk^h the criterion menrwry entry Is configured, and the control logk: is operative 

20 to (i) interpret the configuratk>n lnformatk>n of the retrieved criterion memory entry to determine whk:h informatton 
from the packet dassffcation request is to be used in the operation, and (ii) perionn the operation using only the 
appropriate inf onnation from the packet dassificatk>n request and corresponding infomnation in the criterion mem- 
ory entry based on the determined configuration. 

25 15. Packet dassification apparatus according to daim 1 , wherein the criterion memory is organized into major divistons 
such that each crfterion memory entry includes different fields assodated respedively with the different major 
divisions, each fiekl being configurable to hold different types of criteria according to configuration information 
contained in the criterion memory entry, and wherein the control logic is operative for each major division to select 
infomnation from the packet dassification reque^ for use in the operation with the respedive field of the criterion 

30 memory entry based on the configuration informatton contained in the criterion memory entry. 

16. Pack^ dassification apparatus according to daim t5, wherein the criterion memory includes three major divisions 
such that each criterion memory entry contains a first field configurable as either a source or destination address, 
a second fiekt configurable as either a source address, a destination address, or as a set of port identifier inf or- 

^ mation, and a third fiekl configurable as either a source address, a destination address, a set of port Identifier 
infomnation, or a s^ of flag information. 

17. A method of managing space in a set of criterion memories used to hold search criteria in a hardware search 
engine, comprising: 

maintaining an ordering of different configuratk>ns of the criterion memories, the configurations being ordered 
according to the total amount of criterion memory storage space required to store criterion memory entries 
using the respective configuration; 

maintaining a s^ of lists indkaling the availability of space in the criterion memory for storing criterk>n memory 
^ entries according to the different configurations; 

determining, for a given search to be perfonmed, which of the configurations is a minimum configuration re- 
quiring the minimum amount of criterion memory storage space to store a criterion memory entry required for 
the search; 

searching for a nninimum available configuration as indicated by the lists, the searching beginning with the 
50 minimum configuration and proceeding in the order of increasing consumption of criterion memory space until 

the first available configuration Is found; and 

alk>cating the minimum available configuration to store the criterion memory entry required for the search, and 
updating the avaaaMity Ksts to Indicate ttiat the alk)cated configuration is no longer available. 

55 1 8. A method according to daim 1 7, further comprising detemnining, if a configuratton other than the minimum config- 
uration is altocated, whether an unneeded portion of the allocated configuration can be used as a different conf ig- 
uratk>n allocak)leto another criterion memory entry, and further comprising updating the availability lists to indk»te 
the avaaability of the (fifferent configuration. 
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